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REMARKS 

Reconsideration of the rejections set forth in the office action is respectfully requested in 
view of the following remarks. By this amendment, claim 18 has been canceled without 
prejudice or disclaimer, and claims 2 and 15 have been amended. Currently, claims 1-17 and 19- 
21 are pending in this application* 

Objection to the specification and abstract 

The Examiner objected to the specification and abstract because of several typographical 
errors. These errors have been corrected. Accordingly, the Examiner is respectfully requested to 
withdraw this objection. 

Objection to claims 2 and 4 

The Examiner objected to the claims because of a lack of antecedent basis for a claim 
term in claim 4. Applicants have amended claim 2 as suggested by the Examiner. Accordingly, 
the Examiner is respectfully requested to withdraw this objection. 

Rejection of claims 1, 3-10. and 12-18 overDelanv. 

Claims 1-21 were rejected under 35 USC 102 as anticipated by Delany (U.S. Patent 
Application Publication No. 2002/0138763). This rejection is respectfidly traversed in view of 
the amendments to the claims and the following arguments. 

Independent claim_l_: 

This application relates to an identity management infrastructure that will enable identity 
management to be performed in a centralized management. Centralizing identity management 
allows services to offload responsibility for identity management to reduce maintenance costs 
associated with identity management and to facilitate dissemination of changes to privilege or 
other identity information on th e network. It also facilitates deployment of new services on the 
network by enabling the new services to rely on the centralized identity management services 
rather than requiring them to develop their own identity management infrastructure. (See 
Specification at page 4, lines 7-14). 
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Applicants discovered that it was possible to implement a centralized identity 
management infrastructure by using two data structures - meta data structures describing the 
network services, and service structures containing the identity management information for 
users of the network services, (see Specification at page 4, lines 23-29), The meta data 
structures describe how data is to be described for a particular service and other aspects of the 
service. The service structures contain the actual data for use by particular users of the service. 
The identity management infrastructure provides a standardized way of storing meta data entries 
and service registration data to enable services to take advantage of the identity management 
services provided by the identity management infrastructure. 

Delany does not teach or suggest the use of meta data structures that describe the network 
services. In the rejection, the Examiner cited Paragraph 130 of Delany as teaching a step of 
obtaining a first meta data record describing a first of the network services. Applicants 
respectfully submit that this portion of Delany does not teach or suggest meta data records that 
describe network services. Rather, the profiles described in paragraph 130 are used by Delany to 
describe the databases so that the database manager 120 can determine which database should be 
accessed to service a particular request. The profiles are not used to describe the network 
services as claimed in independent claim 1 . 

To understand the difference between Delany and the present invention, paragraph 130 
should be read in context. In paragraph 128, Delany states that Fig. 1 shows identity server 40 
communicating with directory server 36. At the top of page 7, still in paragraph 128, Delany 
states that "Fig. 3 depicts an exemplar architecture for supporting multiple directory servers..." 
Delany then continues in the next several paragraphs (including paragraph 130) to describe 
aspects of the directory server 36. Thus, Delany uses paragraph 130 to describe an aspect of how 
the directory server 36 may be used to determine which directory from a plurality of directories 
may be used to service a particular request. Once a directory has been selected, the manner in 
which the directory server operates to service the request is described in connection with Fig. 4 
(paragraphs 135-142), which applicants discuss in greater detail below. 

In Delany, when a database client such as one of the applications 150 (42-48) would like 
to access a directory, the database client will interact with the database manager 120 by calling 
base DB object 152. (Paragraph 135). Base DB 152 calls database manger 120 indicating the 
operation and search base for the data operation. (Par. 136). The database manager checks the 
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profiles (122-128) associated with the agents (130-136) to determine which data store 36a-36d 
can support the operation. Thus, the profiles are used to determine which database should be 
used, and arc not used to describe the network services (or clients) that are accessing the 
database. 

In paragraph 136, Delany teaches that "each data store is a particular type of data store, 
has its own set of operations that it supports, and has its own search base that it supports." The 
profiles are used to describe the data store. Additional details about the profiles are contained in 
paragraph 130, which was cited by the Examiner. In paragraph 130, Delany teaches that the 
profiles represent configuration information including, among other things, the host name, port 
number, name space, login name, password, and support operations. 

When read in context, it is clear that paragraph 130 of Delany is referring to the host 
name of the computer that is implementing the data store, the port number on the machine that 
should be used to access the database, the name space associated with the data on the database, 
the login name and password information required to gain access to the database, and the types 
of operations that may be supported on the database. Thus, the profiles discussed in paragraph 
130 of Delany, and shown in Fig. 3, describe identifying information associated with the 
databases that are part of the directory server, and are not meta data structures describing the 
network services as claimed. 

Once a directory has been selected, the directory server 36 (see Fig. 3) enables 
applications 150 to obtain access to data stored in the data stores 36a-36d. The manner in which 
the data is stored in the data stores is described in paragraphs 139-142. As discussed in these 
paragraphs, information is organized into entries, each of which includes a set of attributes. Each 
attribute has a type, one or more values, and associated access criteria. The type describes the 
kind of information contained in the attribute, and the value contains the actual data (paragraph 
140). One of the main points of Delany appears to be in the differentiation between types of 
attributes in which some of the attributes are required and some are allowed. The collections of 
information about required and allowed attributes are directory schemas. (par. 141). The 
directory schemas do not describe the network services, however, and thus arc not meta data 
records as claimed in claim 1 . 

Paragraph 142 provides examples of groups of attributes that maybe used to store an user 
identity "profile", a group identity "profile", an user organization identity "profile". Although 
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Dclany uses the same word "profile" to describe the collection of attributes that will be used to 
describe user identity, etc., it is clear that these "profiles" arc different than the profiles 122-128 
that arc used to describe the content of the data stores. Moreover, these profiles are different 
than meta data records claimed, since they arc not used to describe the network services bur 
rather are used to describe the manner in which a particular user record is organized. 

Claim 1 recites a method of managing identity information on behalf of network services. 
The method includes the steps of obtaining a first meta data record describing a first of the 
network services, and utilizing the first meta data record to obtain a first service data record 
containing first identity management information for an user of the first network service. Delany 

does not teach this method. 

Specifically, Delany fails to teach or suggest using meta data records to describe network 
services. The profiles 122-128 described in paragraph 130 that was cited by the Examiner do not 
describe the network services, but rather describe the databases that may be used to store 
information so that the information may be made available to the applications. Moreover, even 
if these maybe considered to be meta data records, these meta data records are not used to obtain 
service data records, but are merely used to decide which database should be used to service the 
request that was received from the applications. Additionally, the profiles described in 
paragraph 142 are similarly not used to describe the network services. Accordingly, Delany fails 
to teach both of the steps claimed in Independent claim 1. For this reason, applicants 
respectfully request that the rejection of claim 1, and those claims dependent thereon, be 
withdrawn. 

Dependent claims 3 and 4: 

As discussed in greater detail in the application, for example in connection with figs. 4-7 
(see also page 5, lines 16-31) one aspect of the invention enables a user interface to be self- 
configuring so that the person developing a new network service is not required to create an user 
interface to enable users to interact with the service when they need to do things like access their 
personal data associated with the service. Specifically, the identity management infrastructure 
accesses the meta data for the service and uses the meta data to configure an user interface 
having the desired fields and buttons that are required for the user to be able to interact with the 
service. This allows applications to be developed without requiring the developer to create the 
user interface that is required to enable the user to perform identity management 
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Claims 3 and 4 are directed to this aspect of the invention, which is not shown by Delany* 
Specifically, claim 3 recites that the method further comprises the step of utilizing the first meta 
data record to create a first user interface for the user. Delany does not suggest that the profile 
122 cited by the Examiner in connection with paragraph 130 should be used to create a user 
interface. Additionally, claim 4 recite$ that the first user interface is dynamically configured 
during creation according to the field information contained in the first meta data record. There 
is no indication that this is performed in Delany either. 

The Examiner cited Fig. 8, and paragraphs 108-109 in connection with the rejection of 
claim 3. In paragraphs 108-109, Delany describes the user manager application 42, not an user 
interface. Specifically, Delany does not teach or suggest in this section that the user interface 
should be "created" using the meta data. Thus, while presumably Delany will have an user 
interface that will allow the user to interact with the system, these portions of Delany do not 
teach or suggest that the meta data record that was obtained in the first step of claim 1 should be 
used to "create" the first user interface. 

Fig. 8 of Delany is described in greater detail in paragraphs 154-156. As described in this 
section of Delany, Fig. 8 graphically depicts the various services provided by the user manager. 
It does not teach or suggest that the user interface should be created from the first meta data 
record describing a first of the network services as claimed. 

With respect to claim 4, the Examiner cited paragraphs 130, 142, 155, and 274 as 
teaching that Delany teaches that the first user interface is dynamically configured during 
creation according to field information contained in the first data record. As discussed above, 
the profiles described in paragraph 130 describe the database, and are not tneta data files 
describing the services. Accordingly, this paragraph does not provide support for the rejection 
since the profiles 122-128 would not be used to create user interfaces. 

Paragraph 142 describes various attributes that may be stoned in an user identity profile. 
This portion does not teach or suggest that the user interface associated with displaying the 
attributes would be dynamically configured using field information contained in a first meta data 
record. 

Paragraph 155 describes different actions an user may perform through an user interface. 
It does not teach or suggest that the user interface should be dynamically configured during 
creation according to field information contained in the first meta data record. 
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■ 

Paragraph 274 of Delany describes in greater detail the user interface that is provided to 
an administrator when the administrator is to create a group. Interestingly, at line 3 of paragraph 
274, Delany teaches that the GUI lists ALL possible attributes that can be included in the group 
profile. If the user selects attributes from a class, then the attributes are added to the group. By 
selecting appropriate attributes, the group may be configured by the administrator. This 
paragraph actually teaches away from using the meta data record to define an user interface, 
since it teaches that the GUI should include all attributes so that the administrator may select 
from amongst the attributes. Thus, this paragraph of Delaney does not teach or suggest a first 
user interface that is dynamically configured during creation* 

For these additional reasons, applicants respectfully submit that claims 3 and 4 are 
independently patentable over Delany. 

Independent claim 9 

Independent claim 9 recites a method of fulfilling identity management information 
requests from a network user, including the steps of obtaining meta data associated with a 
network service. As discussed above, Delany does not teach or suggest the use of meta data 
associated with a network service. Accordingly, for this reason* independent claim 9 should be 
found to be patentable over Delany. 

Claim 9 further recites the step of using the meta data to present an identity management 
user interface to an user of the network service. As discussed above in connection with 
dependent claims 3 and 4, Delany does not teach or suggest the use of meta data to present an 
identity management user interface. Accordingly, for this additional reason claim 9 should be 
found to be patentable over Delany. 

The Examiner cited several of the same sections as support for the rejection of claim 9. 
Since these sections of Delany have been discussed above, they will not be re-addressed in 
connection with this rejection. Additionally, the Examiner cited paragraphs 1 1 6-1 18 as teaching 
the step of "obtaining meta data associated with a network service." Applicants respectfully 
submit that paragraphs 116-118 instead teach a way in which the system shown in Delany may 
be used to authenticate and perform authorization services on behalf of web servers to enable the 
system of Fig. 1 to enable a decision to be made as whether particular requested services should 
be provided to the user. Accordingly, these paragraphs do not address how the user should fulfill 
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identity management information requests "fiom a network user" but rather teach how the 
system should be used to handle authentication and authorization requests from a web server. 
Accordingly, for this additional reason, applicants respectfully submit that claim 9 is patentable 
over Delany. 

Claims 10-14 depend on claim 9, and are therefore patentable for at least the same 

reasons. 

Independent claim ,15. 

Independent claim 15 has been amended to recite the features formerly set forth in 
dependent claim 18. Specifically, claim 15 has been amended to recite that the data access 
daemon comprises a communications layer configured to facilitate communications with the 
interface layer, and a data access daemon core configured to provide identity management 
services. In addition, claim 1 5 has been further amended to recite that the identity management 
services comprise at least one of authentication and authorization services. 

In the rejection of claim 18, the Examiner cited Fig. 3, paragraphs 128-129. and 132, as 
teaching a data access daemon core that provides identity management services. As discussed in 
greater detail above, paragraphs 128 and 129 teach the general structure of the directory service. 
Paragraph 132 describes how database clients interact with database manager to extract data 
from the data stores. None of these paragraphs teach or suggest that the directory server 36 
shown in Fig. 1 and shown in greater detail in Fig. 3, should perform identity management 
services such as authentication and authorization. Rather, these services are performed by other 
entities in uie system such as the access server 34 and the identity server 40. Accordingly, for 
these reasons, applicants respectfully submit that claim 15, as amended, is patentable over 
Delany. 

Conclusion 

In view of foregoing claim amendments and remarks, it is respectfully submitted that the 
application is now in condition for allowance and an action to this effect is respectfully 
requested. If there are any questions or concerns regarding the amendments or these remarks, 
the Examiner is requested to telephone the undersigned at the telephone number listed below. 
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If any fees are due in connection with this filing, the Commissioner is hereby authorized to 
charge payment of the fees associated with this communication or credit any overpayment to 
Deposit Account No. 502246 (Ref: NN-13060). 



John C Gorecki, Esq. 
P.O. Box 553 
Carlisle, MA 01741 
Tel: (978) 371-3218 
Fax: (978) 371-3219 
john@gorecki.us 
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